fix(security): trusted-proxy-aware client IP resolution for rate limiting - #49

Summary

Both rate limiters derived "client IP" incorrectly, in opposite ways:

• login_rate_limit.py trusted a client-supplied X-Forwarded-For header unconditionally, with no trusted-proxy allowlist. Any client could reset its own login-brute-force bucket on every request just by sending a fresh X-Forwarded-For value, defeating the 10-attempts/15-minute limit entirely on any deployment where the header isn't stripped/overwritten at the edge (common for a self-hosted app that may be exposed directly).
• rate_limit.py did the opposite: it ignored X-Forwarded-For entirely and always used request.client.host, which -- once actually behind a reverse proxy/load balancer in production -- is the proxy's own IP for every request, collapsing the general 120 req/min limit into a single shared bucket for every real client.

Changes

• New app/core/client_ip.py::get_client_ip(), shared by both limiters:
  • Only honors X-Forwarded-For when the immediate TCP peer is in the new TRUSTED_PROXY_CIDRS setting (comma-separated CIDRs, empty by default -- so XFF is never trusted out of the box).
  • Walks the header right-to-left and returns the first hop that isn't itself a trusted proxy, so an attacker can't defeat this by prepending a fake IP before the real proxy's hop.
• login_rate_limit.py and rate_limit.py both now call get_client_ip(request) instead of their own divergent logic.

Test plan

• Added api/app/tests/test_client_ip.py (6 tests, all deterministic, no network/Redis needed): XFF ignored with no trusted proxies configured; XFF ignored from an untrusted peer; XFF honored from a trusted peer; correct hop selection through chained trusted proxies; a spoofed prefix hop from an attacker connecting directly to a trusted proxy is still correctly bypassed in favor of their real IP; no-XFF-header fallback.
• ruff check ., mypy ., pytest -- all clean (45/45 backend tests)
• End-to-end against a live docker-compose stack: with uvicorn's own loopback proxy-trust explicitly disabled (--forwarded-allow-ips="", matching a real deployment topology where the app isn't directly behind a trusted proxy), hammering /api/auth/login with a different spoofed X-Forwarded-For on every request no longer resets the bucket -- the 11th attempt within the window correctly returns 429, and Redis shows a single login_rl:127.0.0.1 key rather than 12 separate spoofed-IP keys.

Note for reviewers: by default (TRUSTED_PROXY_CIDRS empty), X-Forwarded-For is never trusted, which is safe but means rate limiting always uses the direct TCP peer. Operators running behind a real reverse proxy/load balancer need to set TRUSTED_PROXY_CIDRS to that proxy's address/CIDR for rate limiting to see real client IPs instead of the proxy's.

Fixes #26